As I mentioned in a new issue, I created against the original code base for SdFat:
greiman#506

I noticed that the code for Teensy boards uses a special driver SdSpiTeensy3.cpp which uses
the SPI call: transfer(buffer, count);

Which on write functions, the code allocates 512 bytes on the stack, then copies the data out of the buffer passed in, to the copy on the stack, as to avoid having the transfer method overwriting the buffer passed in.

As you know, 8 years ago we added the alternative transfer method: transfer(txbuf, rxbuf, count); where either of these could be nullptr. Using this instead removes the need for the temporary copy on the stack.

Note: this is not the fix I would do, now, and from the comments by @greiman on the issue, he probably would not accept. His current released sources, now has the ability to do the exact same stuff without the need for a special driver. As the SdFatConfig.h file now has the ability to choose a few different ways to do these transfers without the need for a specialized driver:

/**
 * If USE_SPI_ARRAY_TRANSFER is one and the standard SPI library is
 * use, the array transfer function, transfer(buf, count), will be used.
 * This option will allocate a 512 byte temporary buffer for send.
 * This may be faster for some boards.  Do not use this with AVR boards.
 *
 * Warning: the next options are often fastest but only available for some
 * non-Arduino board packages.
 *
 * If USE_SPI_ARRAY_TRANSFER is two use transfer(nullptr, buf, count) for
 * receive and transfer(buf, nullptr, count) for send.
 *
 * If USE_SPI_ARRAY_TRANSFER is three use transfer(nullptr, buf, count) for
 * receive and transfer(buf, rxTmp, count) for send. Try this with Adafruit
 * SAMD51.
 *
 * If USE_SPI_ARRAY_TRANSFER is four use transfer(txTmp, buf, count) for
 * receive and transfer(buf, rxTmp, count) for send. Try this with STM32.
 */

We could simply use: #define USE_SPI_ARRAY_TRANSFER 2

The only thing this would miss, is the ability to pass in: that I am using the built-in SD adapter on T3.5/3.6/4.x to the SPI driver, and it will map that to the SPI pins on the adapter, which I have not seen nor heard of anyone using?

However, this updated code has not been merged into your fork, so went with this
limited update for now.